The following definitions are introduced for the purpose of clarity.
AAA: Authentication, Authorization and Accounting. AAA is a common name for both RADIUS and DIAMETER, i.e. solutions providing customer care, control and billing in a large IP network.
DIAMETER: A successor of RADIUS with increased security and scalability features compared to its predecessor RADIUS. It is currently under standardization by the IETF.
DHCP: Dynamic Host Configuration Protocol. DHCP is an Internet Engineering Task Force (IETF) standard for allocating Internet Protocol addresses and other configuration information to User Systems. User Systems can either be Fixed Hosts or Mobile Hosts. The allocation is done each time when the User System is started. A DHCP server allocates the information, which is then transferred to a DHCP client. An Internet Service Provider or an IT-department controls the DHCP server. The DHCP client is a SW functionality embedded in the User System.
FA: Foreign Agent. The primary responsibility of an FA is to act as a tunnel agent which establishes a tunnel to a HA on behalf of a mobile node in mobile IP.
HA: Home Agent. The primary responsibility of the HA is to act as a tunnel agent which terminates the mobile IP tunnel, and which encapsulates datagrams to be sent to the Mobile Node in mobile IP.
IETF: Internet Engineering Task Force. The IETF is the standardization organization for the Internet community.
IP: Internet Protocol. IP is a network layer protocol according to the ISO protocol layering. IP is the major end-to-end protocol between Mobile and Fixed End-Systems for Data Communications.
MIP: Mobile IP. MIP is an IP mobility standard being defined by the IETF with the purpose to make IP networks mobility aware, i.e. providing IP entities knowledge on where a Mobile Node is attached to the network. The standard includes the definition of a Foreign Agent and a Home Agent.
MN: Mobile Node. The MN comprises both the Terminal Equipment (TE) and the Mobile Termination (MT).
RADIUS: Remote Authentication Dial-In User Service. RADIUS is the currently, widely deployed AAA protocol. It is a protocol for carrying authentication, authorization, configuration and accounting information between a network access server and a centralized ISP RADIUS server.
Mobile IP is defining a home agent as the anchor point with which the mobile node always has a relationship, and a foreign agent, which acts as the local tunnel-endpoint at the access network where the mobile node is visiting. While moving from one IP subnetwork to another, the mobile node point of attachment (FA) may change. At each point of attachment, mobile IP either requires the availability of a standalone foreign agent or the usage of a co-located care-of address in the mobile node itself.
In general, the Internet protocol datagrams are routed from a source to a destination by having routers to forward datagrams from incoming network interfaces to outbound network interfaces according to information in routing tables. The routing tables typically maintain the next-hop (outbound interface) information for each destination IP address. The destination IP address normally embeds information that specifies the IP client's point of attachment to the network. Correct delivery of datagrams to a client's point of attachment depends on the network identifier portion contained in the client's IP address, which however has to change at a new point of attachment. In order to alter the routing of the datagrams intended for a mobile node to a new point of attachment it is possible to associate a new IP address with the new point of network attachment. On the other hand, to maintain existing transport protocol layer connections as the mobile node moves, the mobile node's IP address must remain the same.
This mobility addressing dilemma is handled in mobile IP by allowing the mobile node to be associated with two IP addresses: a static, “home” address and a dynamic, “care-of” address that changes at each new point of attachment to the Internet. Only the care-of address changes at each new point of attachment, the home address remains unchanged. The home IP address assigned to the mobile node makes it logically appear as if the mobile node is attached to its home network. The home address is the IP address where the mobile node seems to be reachable for other Internet clients and servers.
When the mobile node is not attached to its home network, a mobile agent that is provided in the home network receives traffic directed to the mobile node's home IP address. The home agent routes (tunnels) that traffic to a foreign agent using the mobile node's current care-of address. The care-of address, which identifies the mobile node's current, topological point of attachment to the Internet, is used by the home agent to route datagrams to the mobile node. If the mobile node is not attached to a foreign network, the home agent simply arranges to have the datagram traffic delivered to the mobile node's current point of attachment in the home network. Whenever the mobile node moves its point of attachment, it registers a new care-of address with its home agent.
The further delivery by the home agent to the foreign agent requires that each datagram intended for the mobile node be modified/extended so that the care-of address appears as the destination IP address. This modification of the datagram is sometimes termed a “redirection.” The home agent redirects datagrams from the home network to the care-of address by constructing a new IP header that contains the mobile node's care-of address as the datagram's destination IP address. This new header “encapsulates” the original datagram causing the mobile node's home address to have no effect on the encapsulated datagram's routing until it arrives at the care-of address. This encapsulation is commonly known as “tunneling” in the sense that the data datagram burrows or tunnels using the new “routing” header through the Internet, while the encapsulated IP header is completely ignored. When the datagram arrives at the foreign agent the new “routing” header is removed and, the original datagram is sent to the mobile node for properly processing by whatever higher level protocol (layer 4) that logically receives it from the mobile node's IP (layer 3) processing layer.
Foreign agents regularly broadcast agent advertisements that include information about one or more care-of addresses. When a mobile node receives an agent advertisement, it can obtain the IP address of that foreign agent. The mobile node may also broadcast or multicast an advertisement solicitation that will be answered by any foreign agent that receives it. Thus, the agent advertisement procedure allows for the detection of foreign agents, lets the mobile node determine the network number and status of its link to the Internet, and identifies whether it is at home or on a foreign network. Once a mobile node receives a care-of address, a registration process is utilized to inform the home agent of the care-of address. The registration allows the home agent to update its routing table to include the mobile's home address, current care-of address, and a registration lifetime.
The IETF internet-draft on the subject of route optimization in mobile IP is written by Charlie Perkins. It carries the title “Route Optimization in Mobile IP”. The current version is “draft-ietf-mobileip-optim-09.txt” and can be found at IETF's website “www.ietf.org/internet-drafts/”.
The route optimization extensions provide a way for corresponding nodes to cache the binding of a mobile node and to then tunnel their own datagrams directly to the care-of address indicated in that binding, bypassing the mobile node's home agent. Extensions are also provided to allow datagrams in flight when a mobile node moves, and datagrams sent based on an out-of-date cached binding, to be forwarded directly to the mobile node's new care-of address.
More specifically, the home agent sends a binding update to the correspondent node, including the current care-of address for the mobile node, when intercepting the first datagram from the correspondent node to the mobile node home network address. The correspondent node is equipped with specific software that understands the mobile IP binding update message. It reads out the care-of address from the binding update and installs it in its binding cache. From this point on, the correspondent node sends subsequent datagrams directly to the mobile node using it's the mobile node's care-of address as the destination address of an IP-IP tunnel. No acknowledgment is required for the binding update message, since additional future datagrams from the correspondent node and intercepted by the home agent will cause the sending of another binding update.
Similarly, when any node (e.g., a foreign agent) has a binding cache entry for a mobile node (and thus has no visitor list entry for this mobile node), and receives a tunneled datagram, then the node receiving this tunneled datagram may deduce that the tunneling node has an out-of-date binding cache entry for this mobile node. In this case, the receiving node should send a binding warning message to the mobile node's home agent, advising it to send a binding update message to the node that tunneled this datagram. The mobile node's home agent can be determined from the binding cache entry, because the home agent address is learned from the binding update (that established the cache entry in the first place.) The address of the node that tunneled this datagram can be determined from the datagram's header, since the address of the node tunneling this IP datagram is the outer source address of the encapsulated datagram. As in the case of a binding update sent by the mobile node's home agent, no acknowledgment of this binding warning is needed, since additional future datagrams for the mobile node tunneled by the same node will cause the transmission of another binding warning.
As part of the registration procedure, the mobile node may request that its new foreign agent attempts to notify its previous foreign agent, by including a previous foreign agent notification extension in its registration request message sent to the new foreign agent. The new foreign agent then builds a binding update message and transmits it to the mobile node's previous foreign agent as part of the registration. The new foreign agent requests an acknowledgment of the binding update from the previous foreign agent. This extension includes only those values needed to construct the binding update message that are not already contained in the registration request message. The authenticator for the binding update message is computed by the mobile node using the security association shared with its previous foreign agent. This notification will typically include the mobile node's new care-of address, allowing the previous foreign agent to create a binding cache entry for the mobile node to serve as a forwarding pointer to its new location. Any tunneled datagrams for the mobile node, that arrive at its previous foreign agent after the forwarding pointer has been created, can then be re-tunneled to the mobile node's new care-of address.
The present invention aims at providing a similar result in the form of route optimization, while not requiring the correspondent node to be aware of the mobile IP protocol. In addition to the above mentioned route optimization draft, the following references are also of general interest for the understanding of the present invention:
Alexander, S. et al; DHCP Options and BOOTP Vendor Extensions; http://www.ietf.org/rfc/rfc2132.txt; March 1997.
Calhoun, Pat et al; DIAMETER Base Protocol; http://www.ietf.org/internet-drafts/draft-calhoun-diameter-17.txt and http://www.diameter.orgl; September 2000
Calhoun, Pat et al; DIAMETER Mobile IP Extensions; http://www.ietf.org/internet-drafts/draft-calhoun-diameter-mobileip-11.txt; September 2000.
Calhoun, Pat et al; Mobile IP Network Access Identifier Extension for IPv4; RFC2794; http://www.ietf.org/rfc/rfc2002.txt; March 2000.
Dierks, T et al; The TLS Protocol, First Version; RFC2246; http://www.ietf.org/rfc/rfc2246; January 1999.
Droms, R.; Dynamic Host Configuration Protocol; RFC2131; http://www.ietf.org/rfc/rfc2131.txt; March 1997.
Knight, S et al; Virtual Router Redundancy Protocol; RFC2338; ftp://ftp.isi.edu/in-notes/rfc2338.txt; April 1998.
Montenegro, G.; Reverse Tunneling for Mobile IP; RFC2344; http://www.ietf.orq/rfc/rfc2344.txt; May 1998.
Perkins, Charlie; IP Mobility Support; RFC2002; http://www.ietf.org/rfc/rfc2002.txt; October 1996.